Practical Datatype Specializations with Phantom Types and Recursion Schemes

Datatype specialization is a form of subtyping that captures program invariants on data structures that are expressed using the convenient and intuitive datatype notation. Of particular interest are structural invariants such as well-formedness. We investigate the use of phantom types for describing datatype specializations. We show that it is possible to express statically-checked specializations within the type system of Standard ML. We also show that this can be done in a way that does not lose useful programming facilities such as pattern matching in case expressions.Comment: 25 pages. Appeared in the Proc. of the 2005 ACM SIGPLAN Workshop on M

A Type- and Control-Flow Analysis for System F: Technical Report

We present a monovariant flow analysis for System F (with recursion). The flow analysis yields both control-flow information, approximating the λ- and Λ-expressions that may be bound to variables, and type-flow information, approximating the type expressions that may instantiate type variables. Moreover, the two flows are mutually beneficial: the control flow determines which Λ-expressions may be applied to which type expressions (and, hence, which type expressions may instantiate which type variables), while the type flow filters the λ- and Λ-expressions that may be bound to variables (by rejecting expressions with static types that are incompatible with the static type of the variable under the type flow). As is typical for a monovariant control-flow analysis, control-flow information is expressed as an abstract environment mapping variables to sets of (syntactic) λ- and Λ-expressions that occur in the program under analysis. Similarly, type-flow information is expressed as an abstract environment mapping type variables to sets of (syntactic) types that occur in the program under analysis. Compatibility of static types (with free type variables) under a type flow is decided by interpreting the abstract environment as productions for a regular-tree grammar and querying if the languages generated by taking the types in question as starting terms have a non-empty intersection. This is a companion technical report, providing additional commentary and proof details, to a paper [11] appearing in Implementation and Application of Functional Languages: 24th International Symposium (IFL’12)

Fairness for Transactional Events

Transactional events are a recent concurrency abstraction that combines first-class synchronous message-passing events with all-or-nothing transactions. Transactional events provide both a sequencing combinator, which permits the description of behaviors in which multiple potential synchronization actions (including communications between threads) either all occur in sequence or none of them occur, and a nondeterministic choice combinator, which permits the description of behaviors in which exactly one of a set of potential synchronization actions occurs. While prior work gave a semantics and an implementation for transactional events, it provided no guarantees about which of the many non-deterministic executions might be exhibited by a program. For concurrent systems, like transactional events, it is natural to expect certain fairness conditions to hold on executions. Intuitively, fairness guarantees that any system component that could (sufficiently often) make progress does, in fact, make progress. In this work, we investigate fairness for transactional events. We give a rigorous definition of fair program executions in transactional events, describe a refined operational semantics that guarantees fair executions, and discuss restrictions and assumptions necessary for the correctness of an implementation based on the refined semantics. This is a companion technical report, providing additional commentary and proof details, to a paper [1] appearing in Implementation and Application of Functional Languages: 23rd International Symposium (IFL\u2711)

A Rational Solution to Cootie

No abstract provided in this article

The Best Way to Knock \u27m Down

Knock \u27m Down is a game of dice that is so easy to learn that it is being played in classrooms around the world. Although this game has been effective at developing students\u27 intuition about probability [Fendel et al. 1997; Hunt 1998], we will show that lurking underneath this deceptively simple game are many surprising and highly unintuitive results

Bounds on a Bug

In the game of Cootie, players race to construct a cootie bug by rolling a die to collect component parts. Each cootie bug is composed of a body, a head, two eyes, one nose, two antennae, and six legs. Players must first acquire the body of the bug by rolling a 1. Next, they must roll a 2 to add the head to the body. Once the body and head are both in place, the remaining body parts can be obtained in any order by rolling two 3s for the eyes, one 4 for the nose, two 5s for the antennae, and six 6s for the legs. This game raises the question: If the game lasts for T turns, what is E[T], the theoretical expected value of the number of rolls required to make a cootie

What\u27s Best?

No abstract provided in this article

Optimal Token Allocations in Solitaire Knock \u27M Down

In the game Knock ’m Down, tokens are placed in N bins. At each step of the game, a bin is chosen at random according to a fixed probability distribution. If a token remains in that bin, it is removed. When all the tokens have been removed, the player is done. In the solitaire version of this game, the goal is to minimize the expected number of moves needed to remove all the tokens. Here we present necessary conditions on the number of tokens needed for each bin in an optimal solution, leading to an asymptotic solution. MR Subject Classifications: primary: 91A6

Optimal Token Allocations in Solitaire Knock\u27m Down

In the game Knock \u27m Down, tokens are placed in N bins. At each step of the game, a bin is chosen at random according to a fixed probability distribution. If a token remains in that bin, it is removed. When all the tokens have been removed, the player is done. In the solitaire version of this game, the goal is to minimize the expected number of moves needed to remove all the tokens. Here we present necessary conditions on the number of tokens needed for each bin in an optimal solution, leading to an asymptotic solution